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(54) Apparatus and method for authenticating transmitted applications in an interactive 
information system 

(57) An executable interactive program is combined 
witti audio/video data for transmission. The program is 

divided (40, 41) into modules, similar to computer files. 

and a Directory Module is created which links program t WG. 7 

modules. Security for the executable application is pro- 
vided (52,53.54) by attaching a signed certificate to 
respective Directory Modules. The integrity of respec- 
tive modules is monitored by hashing (46) respective 
modules and including (50) respective hash values in 
the Directory Module. A hash value of the. Directory 
Module containing the other hash values is generated 
(46). encrypted (51) and attached (53,54) to the Direc- 
tory Module. At a retjeiver the certificate is decoded and 
checked for authenticity of provider. If the certificate is 
authentic the program may be executed but only if 
receiver generated hash values of respective program 
modules are identical to corresponding hash values 
contained in the Directory Module. 
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Description 

This inveotion relates to a method and apparatus for insuring that data accepted by an interactive tel^ision system 
■'^'r™e.s.onnV)systemsareKno«nfrom1o^ 

vision systems typically involve the transmission of programming and/or control data 

*."^iSl"Zn»«», »«l pro^ng a«»<«d »«o. and POaata «. '««»*:»,P™?.^'; Z^iSS?™, 

l^2 t^^ .^L^^n:^v6e6 in the Directory Module. The modules are then cond-toned for transm.ss.on. 
The invention will be descrtoed with the aid of the following drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 is a block diagram of an interactive TV signal encoding system embodying an aspect of the present 

invention; , .... .. 

FIGURE 2 is a pictorial diagram of a portion of an exemplary AVI sjgnai 

cir-i IDC c ic a taNp of the contents of an exemplary transmission unit header. 

F GUrI 6 is rS^e <5^e corSer^of an exemplary Directory Module of a AVI application embodying the .nv«n|on. 
fIgUrI 7 raC dLgram S^Lra^^ of the process of applying security/protection to an AVI appl.cat,on embod- 

FIGURESin Wock diagram of exemplary receiver apparatus embodying the ''1'^°^ orocessor 
FIGURE 9 is an expanded block diagram of an exemplary processor wh.ch may be implemented for the processor 

FlJu%Tlo's a r TaS sho^ng operation of a portion of the receK^er apparatus of FIGURE 8. and which 

Sre"i 1 r:™"^ ^l^pi^tS ess ^r au^enticating a certif .ate a^ is an en^iment of .e 

" fTg?re"i2 is a pictorial representation of a preferred Directory Module format accord-.ng to the invention. 

.eT^d-rsSrs-^^^^^^^^ 

" "^?;Srri;!;^tT?lG5^M'Tr^S5r^^^ at Hsoulputport. anaudio-video-mteractive CAVO pro- 

gram sSsuc^SU g'JntSte^ema.ive AVI programs. A program guide, which f -"-."'^.^-^^^^ 
Sg thHlSi^ *deo and interactive components of respective AVI 

is provided in a transmission format similar to the AVI programs by a processing element 27. The program guKJe ana 
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respective AVI programs are applied in transport packet form to respective input ports of a channel multiplexer 28. The 
channel multiplexer 28 may be of known construction tor equally time division multiplexing respective packet signals into 
a single signal stream or it may be a statistically controlled multiplexer. The output of the multiplexer 28 is coupled to a 
forward error coding (FEC) and signal interleaving apparatus 31 . which may include Reed-Solomon and Trellis encod- 
5 ers The output of the FEC 31 is coupled to a modem wherein the multiplexed signal is conditioned for application to. 
for exarrple a satellfte transponder An exemplary statistically multiplexed packet signal is illustrated in FIGURE 2. and 
an exemplary format for respective packets is illustrated in FIGURE 3. 

AVI formation is controlled by a system program controller 5. Program controller 5 may have a user interlace by 
which particular programs and respective program signal components are selected. The program controller assigns 
10 respective SCID's for respective audio, video and interactive components of respective programs. The presumption is 
made that respective receivers will access a program guide to determine which SCID's associate AVI program compo- 
nents and then select transport packets from the trarismitted signal stream containing the associated SCID s. The 
audto' video and interactive components are assigned different SCID's so that one or more of the components of one 
AVI program may conveniently be utilized In the formation of alternate AVI programs. Using differing SCID's also facili- 
15 tates editing audio from one program with video from another etc. 

A given AVI program may include a variety of signal component sources. Shown in FIGURE 1 are an interactive 
component source 10. a video source 1 7. and first and second audio sources 20 and 23 (bilingual audio). The controller 
5 communicates with respective sources for time management and/or enabling functions. The source of video signal 1 7 
is coupled to a video signal compression apparatus 1 8. which may compress signal according to the video compression 
standaid promoted by the Moving Pictures Experts Group (MPEG). Similarly the respective audio signals from the 
sources 20 and 23 are applied to respective compression apparatus 21 and 24. These compression apparatus may 
compress the respective audio signals according to the audio compression standard promoted by the Moving Pictures 
Experts Group (MPEG). Associated audio and video signals compressed according to the MPEG protocol are synchro- 
nized with the use of presentation time stamps (PTS). which are provided by a timing element 15. For '"sight into hw 
the audio and video may be temporally related. the,reader's attention is directed to INTERNATIONAL ORGANIZATION 
FOR STANDARDIZATION. ISO/IEC JTC1/SC29/WG1 1: N0531. CQDING OF MOVING PICTURES AND ASSOCI- 
ATED AUDIO. MPEG93. SEPTEMBER. 1993. _j oc 
The compressed audio and video signals are applied to transport packet formers or processors 19, 22 and 25. 
Audio and video transport packet processors are known and will not be described. Suffice it to say that the packet proc- 
essors divide the conpressed data into payloads of predetermined numbers of bytes and attach identifying headers 
including SCID's as indicated in FIGURE 3. For detailed information on a video signal transport packet processor, the 
reader is directed to United States Patent No. 5.168.356. The packet processors are coupled to the packet multiplexer 
which time division multiplexes the signal components. The transport packet processor may include a buffer memory 
for tenporarily storing packetized data to accommodate the multiplexer senrtdng other components. The packet proc- 
35 essors include PACKET READY signal lines coupled to the multiplexer to indicate when a packet is available. 

Interactive programs are created, via known techniques, by a programmer operating the interactive component 
source or programming element 10. which may be a computer or personal computer (PC). In forming the applicaton 
the programming element 10 interlaces with a memory 1 1 and memory controller 12. and the completed application is 
Stored in the memory 1 1. After completion, the application may be condensed or translated to some native code to con- 

40 serve signal bandwidth. . . , 

In the formation of the application, portions of the programs are formatted into modules, transmission units and 
packets as shown in FIGURE 4. The packets are sirhilar in form to the transport packets described above. A transnriis- 
sion unit consists of % plurality of transport packets. Each transmission unit includes a header packet which includes 
information descriptive of the transmission unit contents, and a plurality of basic packets each of which includes a por- 

4S tion of the codewords of the application. A module is divided into transmission units to facilitate interleaving of informa- 
tion from different modules. Preferably, interleaving of transmission units is permitted, but interleaving of transport 
packets from different transmission units is not. For a more detailed description of the formation of an application and 
transmission units etc. the reader is refered to United States Patent No; 5.448.568. . , ^ , ^. u 

Modules are similar to computer ffles. and are of different types. A first type of module is a Directory Module which 

50 contains information to interrelate respective transmission units and modules as an application. A second module type 
is a Code Module which comprises executable code necessary to program a connputing dwice at a receiver to perform 
or execute the application. A third module type is a Data Module. Data Modules include non-executable "data" used in 
the execution of the application. Data Modules tend to be more dynamic than Code Modules, that is Data Modules may 
change during a program while Code Modules generally do not A fourth type of module is designated a Signal Module. 

55 This module is a special packet including information to trigger receiver interrupts, which may be utilized for synchroni- 
zation of e.g.. video with application program features, or to suspend operation of an application, or to re-enable oper- 
ation of a program etc. Synchronization is effected via inclusion of presentation time stamps. Data. Directory. Code and 
Signal Modules are examples of the PC-data. _j ■ 

The respective modules may be error coded by the programming element 10. For example the entire module may 
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and/or the location of the last code/data byte 'n the m ^.^^^^ ^^^1^ 

Table II of FIGURE 6 illustrates '^P^f J^f,.^^tSiSina^^^^^ type, a field which includes type 

includes a header with an Application .dertW.^. '"^^^^^^^ application, afield indicating 

c^alitiers. a field which indicates the amoum^ m^^^^ 

the nurrtoer of modules cont^nedUn the aPP.''ca*on and ^ ♦'^ ^^^^^^ , fields listed above, or those 

include security data such as airthentcating date. It w, I ''^^^^^rDTSto.^ McSule includes data for each module 

that follow, need not occur in the order illustrated. A cfate^'*°" Ce is S ^e^^ is a list of respective appli- 
similar to the header data for the respectn,e rruxlul^ln acWmo^^ 

cation module names in ASCII format. The data sejon for ^^^^^^^ 5le naively, thisdata may be included 

s:™rrr;r^on^^^^^^^ 

transmission units and transport pacl<etshowever^tt;een^^^ 

i:rtrndgTn:^25^/jr:^^^^ 

The packet multiplexer 1 6 is arranged to P™^'^^ contention between the 

iCe^rtrcorc^errnsr^^^^^^ - - ~ " 

sailed in^gita. signal proce^-g will -^'^^^^^rra^^^^^^^^^ "'"^'^ 
Suffice it to say thatthe packet multplexer 16 may be ".^^ "^^^ output port. A state machine may 

conWte securt, ood« resident In all AVI '""1 S^SSS; OeI Hie algodlh™ 

,og.aph,ueingmeRlvest.Stai*r.ard«te™^^^ 

40 With Directory Modules, and hash values generated over respecbve ""^^^^P"^' nln^e resides in the lact that sig- 

nificantly speed up the operation. 

Consider the quotients Ql and Q2 defined asjoHo^ qi and 02 are whole number 

S^/N=Q1.R1 : S.R1/N=Q2.R2; R2=D;H S =D(mc^N). T^^ 

can?e shovel that a fast check on the signature may be performed as follows. 
At the receiver, extract S. Ql . Q2 from the Directory Module and; 
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1. compute A=S 



2 conrpute B = Q1 times N 

3. compare A > B; If A< B quit, signature cannot check. 
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else H A> B 



4. compute C = A- B 

5. compare C < N; If C > N quH. signature cannot checK 

5 

else if C < N 

6^ conrpute E = C times S 
7. compute F = 02 times N 
10 8. Compare E > F. If E < F quit, signature cannot checK 

else if E > F 

9. connpute . G = E • F 
15 10. Compare G = D . if not, signature does not check. 

Note that all arithmetic operations are simple multiplications or subtractions. The detection of an erroneous signature 
may occur at steps 3, 5, 8 or10. If an erroneous signature is detected at steps 3 or 5, very little computational time has 

been expended. . ^ 

20 The AVI receivers are provided with the putflic keys (and desirably helping quotients Q1 and Q2) of the respective 
system providers for decrypting signed certHicates included with PC-data to determine program authenticity. H program 
authenticity is not <;onfirmed. the received application Is immediately dumped from the receiver. Central to such a secu- 
rity system is the assignment of unique identifiers. ID'S, to application providers and the system controller or server. The 
system controller allocates unique e.g. 32-bit ID'S to each trusted AVI application provider and also issues a certificate 

25 for the application provider's public key The certificate is essentially ttie system controller's digital signature on the 
application provider's public key and includes fields such as the expiration date of the certHicate. the ID of the provider, 
and a limit on the amount of storage an application with this ID can use in the file system of the receivers. The system 
controller may employ a plurality of different private-public key pairs, and the certificate may include flags to designate 
which of the plurality of public keys the receiver should use to decrypt respective certificates. 

30 A certificate for application providers will nominally include: 

CERTIFICATE_FLAGS (which identify tiie certificate type and may include the system controller's public key flag); 
PROVIDERJD. (which indicate length of provider ID); 
PROVIDER_EXPIRE. (which indicates application lifetime); 
PR0VIDER_AUTH0RI2ATI0N_FLAGS. 

35 PROVIDER_STORAGE_LIMIT. (which indicates allotted receiver memory); 
PROVIDER_NAME, (tiie application provider's name) 
PROVIDER„FlXED_CERX (which is the providers public key). 

This foregoing certificate infonnation is hashed modulo 128. and ttie hash value is appended thereto. 

The CERTIFICATE_FLAGS mentioned above include authorization flags which granVdeny ttie receiver processors 

40 access to privileged aaions. Exarrples o1 representative privileges accessed via flags are listed immediately below and 
include; 

1 . ttie alDility to ife downloaded from a broadcast link; 

2. ttie ability to be downloaded from a local link (e.g. connected via a local IRD port); 
45 3 ttie ability to be downloaded from a local remote link (e.g. via a telephone link); 

4. The ability for an application to switch tracks in the context of the same program (e.g. to switch between video 
tracks 1 and 2); 

5. ttie ability to establish a broadcast connection (e.g. to change TV programs or channels): 

6. ttie ability to establish a local connection; 
so 7. the ability to establish a remote connection; 

8. ttie atDility to corrtrol external devices; 

9- ttie aljility to download unchecked modules: 

1 0 the ability for an application to use cryptographic features: 

1 1 . the ability for an application to request the user for permission to access files which have user restrictions; and 
55 1 2. ttie ability to activate a resident OCODE monitor for remote debugging. 

These flags are part of botti the provider certificate and the application authorization field directory An application must 
have the authorization flags set at both locations before it is permitted to perform ttie privileged action. Respective 
receivers contain a BOX auttiorization mask, in nonvolatile storage, which is programmed to permrt access to particular 
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privileges, or to preverrl certain privileged actions. 

Each application provider selects his own cryptographic public-private key pair, and has his public key certified by 
the AVI system controller (for example by notarized request). The application provider is constrained by certain guide- 
lines in selecting the public key. The constraints relate to the capabilities of the receiver hardware. In particular, near 

5 term consumer electronic receivers will include minimal memory and relatively unsophisticated processors, factors 
which affect authentication processing speeds and times, and thus the size and form of public keys. Examples of con- 
straints may be that public keys are to be 512 bits or less and that the number of bits be a power of two etc. 

A special group AVI system ID may be reserved for programs designed to perform receiver or system maintenance. 
This system ID will be attached with a service provider ID. If a program contains both the special group ID and an 

10 authentic provider ID, the corresponding maintenance program may obtain access to more secure portions of the 
receiver, depending upon the ID of the particular provider. For example the application provider may be the system con- 
troller arxi the attached application may be for updating entitlements in a smart card, or performing a system perform- 
ance check. Alternatively, the application provider may be associated with impulse buying commercials and the 
program may be related to checking a users debits against his credit, or to facilitate revenue collection, etc. On the other 

75 hand, if a group ID is not the special group AV! system ID, the functions availatrfe to the application may be limited to 
functions availat^le to all applications. 

Manufacturers of particular receiver apparatus may be assigned special manufacturer ID's. Any application having 
the manufacturer ID may be authenticated by a special autherrtication process, resident in the receiver, and imple- 
mented by the manufacturer during assemtjiy of the receiver. Programs containing the manufacturer ID will access only 

20 receivers produced by the particular manufacturer, and may function to access a particular set of functions built into the 
receiver by the manufacturer. This type of application may be utilized to upgrade receiver operating software. 

There may also be network operators who have software/hardware resident in particular receivers. These network 
operators may also be assigned special ID's to allow selective access to the software/hardware of all network receivers. 
The network operators may include their own authentication process resident in the software/hardware of the network 

25 receiver. 

Whether an application is a special system type, or a manufacturer type or a network type is indicated in the Direc- 
tory Module (Table II) in the Application Type field. The Application Qualifier field may include information identifying the 
manufacturer, or network operator, etc. 

Security is applied to an application as follows. After an application provider has generated an application and 

30 formed respective modules including the Directory nrxxJule, he determines which parts of the application are to be pro- 
tected. In all instances the Directory Module will be protected. In addition each module containing an entry point will be 
protected. Modules without entry points are protected at the providers discretion, and Data Modules are protected at 
the providers discretion. It should be recognized that portions of the data in data modules may frequently change, and 
thereby put a relatively heavy security processing burden on the encoder and receiver, if Data Modules are protected. 

35 Therefor Data Modules may frequently be transmitted unprotected. Having selected the modules to be protected, the 
provider forms a list of the modules selected for security protection, and the mode of protection for respective modules, 
and enters this list in the Directory Module in the fields designated security information. In a particular AVI system this 
module list may be included in general directory information i.e., the first security information portion of the Directoiy 
Module. In an alternative AVI system, information indicating whether a particular module is protected may be included 

40 only in the further security information fields of the respective module in the directory. Part of the receiver system pro- 
gramming will include a routine to examine the Directory for module security information, and perform security process- 
ing on respective modules according to this information. 

Module protection itiay take several forms. The first is simply to encrypt the selected module with the application 
providers private key A second method is to perform a "hash" function over the module and include the "hash" value in 

45 the Directory Module in the further security information field for the respective module. A third method is to perform a 
hash function over the module, include the hash value in the Directory Module and encrypt the selected module with 
the application providers private key. A fourth method perfornns a hash function over the selected module, attaches the 
hash value to the module, encrypts the nnodule plus hash value, and places a replica of the encrypted hash value in the 
Directory Module. In each of the foregoing examples, security processing of the Directory Module is done after all other 

50 modules are processed and the security information for respective modules has been entered in the Directory Module. 
The prefened method comprises performing hash functions over respective modules, inserting the respective hash 
values in the further security information fields of the directory module and subsequently performing a hash function 
over the Directory Module. The hash value of the Directory Module is then encrypted with the providers private key.. 
A trusted application provider will be assigned a signed certificate which includes items such as the providers pub- 

55 lie key. the providers ID. an expiration date of the certificate, possibly ttie amount of storage allocated the provider at the 
receiver etc. This certificate is signed with the system controller's private key. TTie encrypted hash value is appended 
to the signed certificate and the combination is appended to the Directory Module. The directory Module and all other 
modules are provided to the system controller in plaintext. Data Modules which are selected for protection and which 
are frequently changing, are protected by means of a signature of the provider on the hash value over the Data Module. 
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which signature is made part of the respective module. 

It is possible that the application provider is in fact an overseer of a subgroup of lesser application providers. In this 
instance, the application provider may provide a suthcertificate signed with the application providers private key and 
including a suk>-providers public key, the sub-providers ID. an expiration date of the certificate, possil^ly the amount of 

5 storage allocated the sub-provider at the receiver etc. This sub-certificate will also be appended to the Directory Module 
along with the certificate assigned the application provider. 

The preferred mode of protection Is not secure in that it does not preclude prying eyes from detecting/interpreting 
the transmitted information. However the protection. i.e.. inclusion of the certificate and hashing of the data, is advan- 
tageously simple to perform and does provide assurance that the data comes f rom an autiiorized source and that the 

10 integrity of the received data is insured, (if authenticated at the receiver). 

Untrusted application. providers, i.e., providers who may be careless in application generation and threaten the 
integrity of an AVI service, are not provided certificates to be appended their respective applications. Applications pro- 
vided by untrusted providers are subjected to certification by a trusted certifying authority. The certifying authority may 
inspect the integrity of the application and then process the applications of the untrusted application providers for pro- 

15 tection purposes, and ultimately pass the pn^cessed application to the system controller. 

Security processing will be further described with reference to FIGURES 1 and 5. FIGURE 1 includes distinct hash- 
ing and encrypting elements 29. and 30, however it will readily be recognized, by ones skilled in the art of digital signal 
processing, that both functions may be performed in software executed by the ^iPC or digital signal processor. DSP. 
which may be included in the element 10. Once the application has been generated and stored {40} in the memory 1 1 . 
the programmer will select/determine {41} the modules which are to be security protected. These modules will be 
tagged with an index (i). The Directory Module is assigned the highest index so that it will be processed last. Each mod- 
ule to be processed is assigned a "Change" flag which is set to a "1 ". The AVI system r^eatedly transmrts the applica- 
tion during an AVI program. Nominally Code and some Data Modules remain unchanged during the program, but some 
e.g.. Data Modules may change. During the repeated transmissions of the application it is prefen-ed not to re-process 

25 unchanged modules for security, but rather only to reprocess the modules which actually change. The "Change" flags 
are established to alert the security processing function which modules require reprocessing due to changes during the 
duration of a program. Initially the "Change" flag of each module to be security protected is set to the change mode. 
The element 1 0 also determines if a certificate from the system controller is available. 

An operating index "i" is set to zero {42} and the first module, M(0). is accessed {43} from the memory 11. The 

30 -Change" flag for the module is tested {44} and reset {45}. If the module has been previously processed and the 
"Change" flag indicates no change, the system jumps to step {56}. increments the index "i" and accesses the next mod- 
ule. If the "Change" flag indicates that a change has occuned in the module, it is applied {46} to a HASH function proc- 
essor 29. The particular hash function is maintained relatively simple to limit processing requirements imposed on 
respective receivers. The function is preferably a one-way function. The hash function should be computationally fast 

35 and extremely difficult to decipher or break. An exemplary hash function is based on a vector W of 256 codewords Wx 
each 128 bits in length. Data to be hash processed (hashed) is segmented into 256-bit exclusive blocks of data D. 
where D = d ^ . dg, da. d4. dase- A basic hash function BH(D) is defined: 

256 

128 

40 BH(D)= 5^ dxWxmod2 '". 

x-1 



If there are n blocks of data D. n values. Bi. Bg. B3. ..B^, each 128 bits in length, of the function BH(D) will be generated. 
45 To compete the hash over the whole data . the intermediate results Bj are combined as follows: Let (Bi.Bj >represent the 
256 number obtained by concatenating the 1 28 blocks Bi and Bj. Then define H(D). the hash over the data as; 

H(D) o BH(©H{...(<BH(©H{<B^.B2>)33934>)- ...).Bn?. 

so Alternatively the function H(D) may be of the form; 

H(D) = B ^XOR BgXOR B3 XGR-.B^. 

A prefen-ed hash function for hashing modules, is the publicly known function MD5 (MD stands for Message Digest and 
55 MD5 is described by R. Rivest. THE MD5 MESSAGE DIGEST ALGORITHM. RFC 1 321 . April 1 992). Once the module 
is hashed, the module is tested {47} to detennine If it is expected to be changing during the program. If it is expected to 
change, the hash value H(D) is not placed in the directory, by rather is appended {48} to the module stored in the mem- 
ory 1 1. (Atternatively. the hash value may be signed (encrypted) with the providers private key. and then appended to 
the module stored in memory 1 1). The index i is incremented {56} and the next module is accessed from memory. If at 
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{47} the module is deterrraned not to change, a test {49} is made to determine if the module is the Directory Module. If 
it is not, the hash value H(M(i)) for module M(i) is placed in the Directory Module {50} in either the first security informa- 
tion field, or in the further security information field for the respective module. The index 1 is incremented {56} and the 
next module is accessed from memory. 

5 If at test {49} the module Is determined to be the Directory Module, the hashed value H(M(i)) is applied to the 

encryptor 30 wherein it is encrypted with the application providers private key. (If desired, the entire Directory Module 
may be applied to the encryptor for encryption at this juncture.) The certificate is fetched {52} and the encrypted hash 
value is appended thereto {53}. and the certificate with the hash value appended is attached {54} to the Directory Mod- 
ule in memory 1 1 . A flag is set {55} which indicates to the data packet processory^rogram controller, that the program 

70 is ready for transmission. The system jumps to step {42} and the index is reset to zero. The system then proceeds to 
check if modules change and only changed modules are rehashed, during repeat transmissions of the application dur- 
ing a program. As noted earlier, an application provider may include other signed information/certificates which may be 
appended to the Directory Module. Signing of suc^ information is performed in the encryptor 30 using the providers pri- 
vate key. 

15 In an alternative embodiment, the encryption step 51 may be eliminated. In a still further embodiment, ail hash val- 
ues for all hashed modules may be encrypted. 

FIGURE 12 illustrates the format of a preferred Directory Module. The Directory Module is in plain text. Only the 
Directory signature (hash value) and the certificate are encrypted, the former vwth the provider's key and the latter with 
the system controllers key. In addition, when respective nradules are hashed, each such module may be preceded with 

20 an ASCII version of some predetermined text associated with the system controIler^Drovlder such as the text 
"OpenTvCTM)" before hashing, so that respective module signatures are, for example, the hash value 
H(OpenTv(TM)+Module). and the Directory Module signature is the encrypted value of H(OpenTv(TM)+Directory Mod- 
ule). This is indicated in Figure V with the t>ox OTV attached to the menrory 11. and is meant to imply that a digital ver- 
sion of the text "OpenTv(TM)" is stored therein and may be multiplexed with the respective modules when they are read 

25 out and applied to the hash function element 29. 

The Directory Module in FIGURE 1 2 illustrates the preferred format for the AVI system designated OpenTv ™ being 
developed by Thomson Consumer Electronics Inc. The formats of certificates, public keys and signatures used therein 
are described immediately below. 

All certificates, keys and signatures will have multiple byte fields in BIG-ENDIAN format This architecture inde- 

30 pendent format facilitates portability across different receiver architectures. Any OpenTV certificate is a combination of 
a fixed structure followed by a variable length part, which includes the public key being certified and the signature of the 
OpenTV controller. 

There are two classes of certificates that will be issued by the OpenTV controller. 

35 1 . Producer(provider) Certificates which are given to application producers. 

2. Server (system controller) Certificates which are specific to a transaction sender to which applications from a pro- 
ducer (provider) can establish secure communications. 

In addition, a USER certificate may be issued by the controller. This certificate will never be parsed internally by 
40 OpenTV, but only made available to the external world. The OpenTV system will only know the size of this certif icate. 
Apart from an Open TV specific 4 byte header, the rennainder of the certificate structure may be maintained confidential, 
and may be a standard X.509 certificate. 

The following are thfe sizes for common parts of certificates. 
GERTIFICATE_FLAGS.LENGTH (4 bytes) 
45 PUBLC_KEY_SIZE_LENGTH (4 bytes) 

An OpenTV controller issued certificate starts with a 32-bit flag structure which describes the certificate. The location 
and meaning of the various flags are described thusly. 

The flag for possible extensions to the OpenTV certificate structure is set for the Basic Open TV certificate; not to be 

set for extensions. The flags are defined as follows 
so BASIC.CERTIFICATE (0x80000000) 

Exactly one of the following 3 flags will be set. 

SERVER_CERT1F1CATE (0x40000000) 

PRODUCER_CERTIFICATE (0x20000000) 

USER_CERTIFICATE (0x10000000) 
55 There is divergence between the SERVER/PRODUCER certificates and the USER certificates as to the interpre- 
tation of the 32 bit field. If the certificate has the appearance of a USER certificate then the last 16 bits of the field are 

actually its size including the initial 32 bit field. 

Regarding the SERVER/PRODUCER flags, after examining the first four bits." the entity being certified is known, or 

the certificate is considered to be an extension beyond the cun-ent system. The next four bits indicate which OpenTV 
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controller public key has been used to generate the signature. They represent a number N from 0-15. If 0 <= N <= 14, 
the N'th embedded public key is to be used. If N 15 then the public key to be used is the latest key received through 
an EXTERNAL trusted channel. Internally in the system the key numbers can only increase. That is. if internally the key 
is 5 and a c©1ificate with key 6 occure and is verified, then the internal key becomes 6 and certificates with keys less 
5 than 6 will not be acc^ted. Finally, if and when all internal keys break, the public key would be accepted only from 
EXTERNAL trusted channel. 

The next byte is resented for a description of the certificate. Currently it is unused. The next two bytes provide infor- 
mation about the Producer/Server and the Key being certified. The first byte contain flags describing the algorithm with 
respect to the public key: this is common to both server and producer. The next and last byte are different for Producer 
10 and Server so they are described separately. 
The algorithm byte flags are: 

RSA_3_WITH_MD5 (0x00008000) 
RSA_WITH_MD5 (0x00004000) 
The last byte for the PRODUCER certificate currently has no flags defined. The last byte for SERVER certificate cur- 
75 rently has one flag defined to indicate whether the server is constrained. From a functional standpoint, the constrained 
server does not require any information about the connecting party when it first establishes a secure link. This makes 
link establishment much faster. 

SERVER_CONSTRAINED (0x00000080) 
The externally available fixed part of a Producer Signature consists of a two byte flags field which specifies the type 
20 of signature, and a 2 byte field which gives the size of the signature. 
PRODUCER_SIGNATURE_FLAGS_LENGTH (2 bytes) 
PRODUCER_SIGNATURE_SIZE_LENGTH (2 bytes) 
Currently only one flag is meaningful, the assisted flag. H the producer's signature algorithm is RSA.3_WITH_N/ID5. as 
specified in the certificate for the producer then the producer has the option of adding additional help data after the sig- 
25 nature for faster checking, and this is designated 

PRODUCER_SIGNATURE_ASSIST (0x8000) 
The Public Key Structure (for RSA) for producers, servers and OpenTV boxes will now be described. For portability, 
the modulus and exponent sizes f^UST BE A MULTIPLE of 4 BTYES. Also OpenTv requires that if a modulus size is 
stated to be S bytes, then the first 32 bits of the modulus when represented in big endian format must be NON ZERO. 
30 This is not a limitation since the size can then be stated to be S-4 or less. 
The public key consists of: 
fixed_pL±»lic._key_t. 
followed by 

exponent (in big-endian byte format) 
35 followed t3y 

modulus (in big-endian byte format) . ^ u r\ t\/ 

A producer/server certificate consists of a cleartext part which contains a descriptor of the certificate by the OpenTV 
controller followed by the public key of the producer/server of data type described above. In addition there is an enci- 
phered part which is the digital signature S of the OpenTV controller on data which depends on the cleartext data. A 
40 producer/server at this stage has a choice of eHher using only S or adding additional data (e.g.. Q1 and Q2) beyond the 
signature to make it easier to check. ^ w 

The producer/server needs to add 4 bytes of information between the Cleartext and the Signature S. and possibly 
some information bd^ond S to assist in checking. The 4 bytes of information include fields for flags and the size of the 
total amount of data consisting of tiie signature and help information. 

45 The sizes of these two fields are: 

CERTIFICATE_SIGNATUREJNFO_FLAGS„LENGTH(2 bytes) 

CERTIFICATE_SIGNATURE.SIZE_LENGTH (2 bytes) 
Only one flag is cun-ently defined, the RSA_3.ASSIST flag. If set. there is help information beyond the signature S. 
which are the two quotients Q1 . Q2 described herein above. This flag is defined; 

so RSA_3_ASSIST (0x8000). . ♦ 

The foregoing describes the state of encryption at ttie module level. This may be overlain with a further encryption at 
the transport packet level. That is. when respective modules are divided into transport packet payloads for transmission, 
the payloads may be encrypted independent of the authentication process. 

Returning to the general descriptton of the system, two way communications between providers and receivers, by 

55 telephone modem for example, will incorporate encrypted communications using RSA or Data Encryption Standard. 
DES cryptography for exarrple. The session key will be set up using public key cryptography. An application must 
present a certified version of the public key of the sen/er with which it wishes to communicate. A session key is estab- 
lished only if the application provider's ID matches tiie server ID on the certificate, and the key exchange will use the 
public key contained in the certificate. 
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FIGURE 8 illustrates in block form, a portion of AVI signal receiver or 1RD including elements d aninverse transport 
packWproLsor a^nal is detected by an antenna 80 and applied to a tuner det^or. 81 . wh^h extracte a part^ar 
W^X band of received signals, and provides a baseband multiplexed packet signal The fr^u^icy band s 
seTSy^user iSough an IRD system controller 89 (hereafter IRD controller) by convenbonal -^t^odsJ^^ 
bS^AVi signals will have been error encoded using, for example. Reed-Solomon forvrart eaor correctng (FEC) 
Sna The ba?^ signals will thus be applied to a FEC decoder. 82. The FEC decoder 82 synchronizes *^e 
SS^^ed^d^ ^vfdes a stream of signal packets of the type illustrated in FIGURE 3. The FEC 12 may provde 
SteauSuSr iServals. or on demand, by for example, memory controller 87. In either case a packet fram|r^ or 
^fonTzin^Sn^isprovidedbytheFEGdrcu^^^ 

ferred from the FEC 82. , ^. . 

Only packets from a single AVI signal may be processed by the receiver at one time In thte e^'^'^j^/^^""'^ 
that Se uS*as no knowledge of which packets to selea This information is confined '^^ P;°^"f " ^'.f 
soedal croaram consisting of data which interrelates program signal components through their respectveSC D s. The 
?Sl SeTs aSg for each program, including the SCID's for the audio, video, and data components of r^ec- 
rv?p^r^ ?ie Sogram guide (Skets D4 In FIGURE 2) is assigned a fixed SCID. When power apph^J to*,e 
r^J ^IRD coSler sl is pro^ammed to load the SCID associated with the program guide into a SCID dete^or 
S^li^h ,™y be Tbank of matciS filters. When the program guide SCID is deleted, the ^^^^^^^l^l^l 
SnSied to route the corresponding packet payload to a predetermined location in the memory 88 for use by the IRD 

IRD controller waits for a programming command from the user via an interiace 90. which Is shown as a key- 
boarbiZSTiSy Lfa convenLal remote control, or receiver front panel swHches. The user may request to view 
fprogram^rkied on channel 4 (in the vernacular of analog TV systems). The IRD controller 89 is programmed to 
ISn SX^TuL list that was loaded in the memory 88 for the respective SCID's of the channel 4 program com- 
Donents and to toad these SCID's in the SCID detector 84. ^ u- * i r^. tr. 

"^R^eS packets of audio, video or data program components, for a desired ^^^^-^^^'^^^^''^^Jl 
the respectiveVudio 93. video 92. or auxiliary data 91 . (94) signal processors respecbvejr. ^f^^^l'^^^l 
rlfaS^nstant rate, but the signal processors nominally require input data in bursts (according to the r«pecbve 
^i^ddSression for examje). The exemplary system of FIGURE 8. first routes respectn^e Packeteto p^e- 
SrrtneSory locations in the memory 88. Thereafter the respective processors 91-94 request the «.mponert 

from the memory 88. Routing the components through the memory provides a measure of desired signal data 

?^^^So%Srj^d data packets are loaded into respective predetermined memory locations to enable the signal 
proc^L^iraSe^Tto the'corrponentdata. Pay.^^ 

L memory aris as a function of the corresponding SCID's. and control signals P^°^'ded ^y ^CID detector. This 
association may be hardwired in the memory controller 87. or the association may be P OQ'^mms^^- ._.-_^„ 

The respe^K/e signal packets are coupled from the FEC ^ to the '"^'T?' ^^^^''^L^Il^ 
86 Only the signal payioads are scrambled and the packet headers are passed by the descrambler ""aje"^ 
of not a MdS is tobe descrambled is determined by the CF flag (FIGURE 3) in the packet prefix, and how it is to be 
desaiSI dir^i b^e CS flag. This packet scrambling is independent of the application module s«^rrty 
jSS^Iirlbed abovUedescra^^^^ 

S«y be i^lized to perform decryption of received certificates and other data as requir^. However in the following 
desCTiDtion of orocessing transmitted applications, decryption is performed by other apparatus. ■ ^„ . , _ 

'"T^Vlfy^em^&eanunSofd^^^^ 

example in FIGURE 8 both of the AUX1 and AUX2 processors may be responsive to the PC-dateportion of an AVIsg 
^f^e iS? processor may be a personal computer. PC. arranged to detect transmrtted stock market data and to 
rnjL^te^ime::??^^^^^ iSerac«ve application. AUX2 may '-.-/^'-f ^ ^^^^^^^^ 
active imoulse buying in conjunction with transmitted interactive commercials. Note, interactivity taci itatea wm 

S'dTa leSne mcJem (no. shown) interconnected with FIGURE 8 systerj. f° ^^^^^^^ 

be Dioarammed to process and execute transmitted applications, particularly for system "«'"t«"^"f ■ I^^^!,^ 
STnSSS to Lecution of transmitted interactive applications will be described in the context of the I RD cortroBer 
Xe^ting 2?h «,e transmitted applk^tion. (It shouW be noted, that interactivity does "^t^^^^^^^ 'TJ^J;"^^^^^^ 
Ser we Js with the provider, though this is one aspect of interactivity. Interactwrty also '"^"i^^f.'^SS^" pj. 
being able to affect the signal/system at the user's end of the system m accordance wrth a transmrtted applicaton. par 

^'^h^Jr^'eV™^^^^^^^ 

tion D SeSjr i a decryptor 97 a modem 98 and an EPROM 99. The hash function generator 96 and the decryptor 
S mari^liSl^ S^^^-^ie «'«ware. The controller processor (^PC) may include random access menwy. 
kS^^ rSi ^1 rmory ROM. for programming general system ■^-^^^^T^.'^ITZ^ Z^. 
tained in the EPROM 99. The ROM and the EPROM are programmed at manufacture so that the system is operable. 
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However in Ihis example, the EPROM may be reprogrammed to update system functions via an interactive transmitted 
program. 

Assume that at manufacture, the system is programmed to look for a system maintenance SCID between 1 «0 AM 
and 4 00 AM on mornings that the receiver is not in use. so that the system provider can update respective recewere 
with new system enhancements. Between 1 :00 AM and 4:00 AM on mornings that the receiver is not in use. the ^PC 
will program the SCID detector to look for packets that contain the system maintenance SCID. and prepare the memory 
88 to receive program data. An example of program module detection is illustrated in FIGURE 10. 

The programming for SCID detection and memory preparation is part of the start up processes {100}. Once the 
SCID detector is programmed the system idles {102} until a packet containing the system maintenance SCID is 
detected. When such packel is detected, the packet is tested {104} to determine if it contains a transmission unit or 
module header. If it does not. the packet is discarded and the system warts {102} for the next applicaton packet. H is 
assumed that the information necessary to load any application program is self contained in the program (TU headers 
or Directory Module header), hence the system is constrained not to load any detected packets until a packet with the 
appropriate header information is available. When an appropriate packet is delected. Its payload is loaded {10^ in the 
memory 88 The system waits {108} for the next system maintenance packet, and when rt is detected it is loaded {110} 
in the memory 88. A test {1 12} is made after each packet is loaded in memory to determine if a complete module has 
been loaded. If the module is not complete, the system jumps back to step {1 08) to await the next packel. If the module 
is complete such is noted in a listing {114). . , ^ . „ . ^ _ -n 

A further test is made {1 16) to determine if the completed module is a Directory Module. If it is. the system will 
immediately attempt to authenticate the application provider. The certificate appended to the Directory Module is 
decrypted {122} and its contents are checked {124). H the contents of the .certif icate are not authentic, a warning display 
is activated to inform the user that an unauthorized provider was delected. Al this point a number of alternatives are 
possible including a) restarting the process at step {100}; b) shutting down the process for twenty four hours; c) dis- 
carding the Directory Module and waiting for the next Directory Module; etc. Figure 1 1 shows the authentication proc- 
ess in more detail If at test {1 6} a Directory Module is detected, the certificate and encrypted hash value appended to 
the module are accessed {1221}. The certificate is applied to the decryptor 97 and decrypted {1222} using the AVI ^- 
tem controller s public key «fhich has been previously distributed to respective receivers and stored in the receiver. The 
decrypted certificate is applied to the jiPC {1241}. The ^PC accesses corresponding items from the EPROM and com- 
pares {1242} relevant corresponding items. For example the certificate will include an ID which is compared against a 
list of authorized ID'S. In addition the ceiiificate may include an expiration time and date which is compared against me 
current time and date etc. If the compared Hems check {1243} against corresponding items stored in the receiver, the 
application provider's public key. which was transmitted in the certificate, is applied to the deayptor and used to deaypt 
(1 244} the encrypted hash value appended to the Directory Module, or to decrypt any other encrypted data provided by 
the application provider. (At this juncture, if the entire Directory Module is enaypted. rt may be accessed from memory 
and decrypted while the application provider's public key is applied to the decryptor.) On the other hand, if the compared 
items prove not to be authentic or the certificate has expired, the warning is displayed {1 30). . . ^ 

If the application provider is proven to be authentic, the Directory Module is applied to the hash function element 
96 and hashed {1 26}, and the hash value is compared {1 28} in the uPC with the decrypted Directory Module hash value 
that was appended to the Directory Module. (In the preferred embodiment an ASCII version of some predeternruned text 
which is associated with the system controller/provider e.g.. •'OpenTv(TM)-. will be atteched to precede respecttve mod- 
ules before hashing so that respective hash values will equal, for example. H(OpenTv(TM)+Module). This is 'ndirated in 
FIGURE 9 by the box OTV attached to the memory 88. and is meant to imply that a digital version of the te)rt 
-OpenTv(TM)- . for dfample. may be stored in memory 88. and multiplexed with the Directory Module when il is r^d 
from the memory.) H the hash values are not identical, the Directory Module is presumed to "^'"de errors and js dis- 
carded fr6m memory, and the fact that the module was previously loaded is erased {134} from the lishng {114}. and the 
system returns to the step {108} to wait for the next packet. 

If the hash value of the Directory Module agrees wfth the appended hash value, the hash values for respectve pro- 
gram modules are retrieved {1 29} from the directory for use in checking the integrity of received program modules. The 
system jumps to step {1 18} which teste whether all program modules have been loaded in memory. If they have not. 
memory addressing for the next module is arranged {120} and the system returns {108} to await the next appropriate 

'^'^f the test at {118} indicates that the application program is completely stored in memory, the respective Program 
modules are checked for transmission integrity. Respective modules are accessed {136} from memory applied to the 
hash function element 96. and hashed {138}. The respective hash values are compared {140} in tfie wrth the ar- 
responding hash values transmrtted in the Directory Module, or appended to the particular module under test, tf the 
hash values do not agree, the module is presumed to contain errors and is discarded {150. 152). else a tes^ is made 
{142} to determine if all modules have been checked. H they have all been tested, a check is made {146} to determine 
If a complete security checked application is resident in memory If not. the system is retumed to step {120} to start lad- 
ing a new module. If the application is complete, it is executed {148}. In this example the program wfll instruct the nP C 
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to access particular data in a program Data Module and reprogram the EPROM with the transmitted data. 

Once execution has begun, the system is programmed to continue to extract program packets from the transmitted 
signal. On reception^ respective headers are examined for version nuirtoer. If the version number for a particular module 
changes, this module will be hash processed, and if the hash value checks, the module with the new version number 

5 will be substituted for the prior corresponding module. 

As indicated, different apparatus in the receiving apparatus may utilize a particular transmitted application, and may 
be programmed to perform the requisite security processing prior to execution of the application. In the preferred 
embodiment, to avoid duplication of programming or hardware, 'the security processing is performed by the IRD con- 
troller. The IRD controller will be alerted when security processing need be performed by information contained in the 

10 program guide. 

Claims 

1. Apparatus for receiving an executable application transmitted in modules including a Directory Module containing 
15 information about further modules, said Directory Module having at least an encrypted hash value over the Direc- 
tory Module and an encrypted certificate appended, which certificate includes an identity of the application pro- 
vider, said apparatus characterized by: 

a memory (88) 

20 a detector (84) for detecting transmitted said modules and storing detected modules in memory; 

means (89. ^PC) for separating said certificate from a detected Directory Module; 
a decryptor (97) for decrypting said certificate and said encrypted hash value; 

a hash function element (96) for hashing detected said Directory Modules to produce a furtiier hash value; 
a processor (|iPC) programmed for authenticating decrypted said certificate, and comparing decrypted said 
25 hash value witii said further hash value, and if decrypted said hash value and said further hash value are equal 

and said certificate is autfientic, permitting execution of said program. 

2. The apparatus set forth in daim 1 wherein said Directory Module further includes hash values of further program 
modules, and said apparatus further characterized by: 

30 

means for accessing said hash values of further program modules from detected said Directory Module; 
means for applying respective said further program modules to said hash function element for generating hash 
values over said further program modules: and wherein 

said processor is conditioned to compare said hash values of further program modules accessed from said 
35 Directory Module with corresponding hash values produced by said hash function element, and permitting exe- 

cution of said program if at least predetermined ones of corresponding hash values are equal. 

3. The apparatus set forth in claim 1 characterized in that fransmitted said Directory Module is encrypted, and said 
decryptor is conditioned to decrypt said Directory Module with said application provider's public key 

40 

4. The apparatus set forth in claim 2 characterized in that said processor includes means to delete from said memory, 
modules for which corresponding hash values are not identical. 

5. The apparatus set forth in claim 1 characterized in that said decryptor and said hash function element are sub- 
45 sumed in said processor. 

6. The apparatus set forth in claim 1 characterized in that said detector includes forward error correcting circuitry. 

7. The apparatus set forth in claim 1 characterized in that transmitted said executable application is transmitted in 
so transport packets, each of which includes a service channel identifier. SCID. and scrambling flags, and said detec- 
tor includes: 

a programmable SCID detector for selecting transport packets having predetermined SCID's from a multi- 
plexed stream of transport [jackets; and said apparatus furtiier includes 
55 a descrambler responsive to said scrambling flags, for descrambling respective packets acconjing to respec- 

tive states of said scrambling flags. 

8. The apparatus set forth in claim 1 furtiier characterized by means for causing a display to indicate detection of sig- 
nal provided by an unauthorized application provider. 
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9. The apparatus set forth in claim 1 further characterized by: 
a source of a digital version of predetermined text; 

apparatus for preceding at least one of said modules, including the Directory Module, with said digital version 
of predetermined text, and wherein ^ ^ j ^ i 

said hash function element is conditioned to hash said at least one module preceded with said digital version 

of predetermined text 

1 0. The apparatus set forth in claim 9 characterized in that said predetern^ned text is OPENTVCTM). 

11. The apparatus set forth in claim 1 characterized in that said Directory Module includes a signature S calculated 
using a RSA algorithm with modulus N and exponent e. and includes quotients Q1 . Q2 derived from the signature 
S by division by the modulus N. and said processor is conditioned to verify said signature S using the quotents Ql 
and Q2 without performing arithmetic division. 

12 A method of processing executable applications wNch are transmitted as modules, in multiplexed packet format, 
said modules including a Directory Module containing information linking respective further application modules, 
said Directory Module having an encrypted certif icate attached which contains information about the P^vider of the 
application, and vihich certificate is encrypted by a system providers private key. said method characterized by: 

20 

detecting and selecting packets including a desired application, and storing payloads of respective packets as 
respective modules; . 

selecting a Directory Module wntin encrypted certificate attached; 
decrypting tiie certificate witti the system provider's putilic key; 
25 Comparing infonnation in decrypted said certificate with corresponding stored data; 

hashing ones of said application modules to produce module hash values; 

comparing said module hash values witii corresponding module hash values toansmitted in said Directory 

^^Sltii^^i application H corresponding produced and transmitted hash values are identical and decrypted 
30 information contained in said certificate is equivalent to said conresponding stored data. 

13 The method set forth in daim 12 wherein said certificate includes an application providers public key and said 
Directory Module has a hash value of said Directory Module attached, which hash value is encrypted with said 
application provider's private key. and said mettiod furttier characterized by tiie steps of: 

extracting said application provider's public key from decrypted said certificate and separating encrypted said 
hash value from said Directory Module; 

decrypting encrypted said hash value using said application provider's public key; and 
comparing decrypted said encrypted hash value with a hash value of detected said Directory Module. 

14 The method set fortii in claim 12 further characterized by appending a digital fonn of the text OpenTv{Tm) to said 
Directory Module prior too hashing said Directory Module, and hashing said Directory Module with said digital form 
of ttie text OpeifTv(tiTi) appended. 

45 15. Apparatus for transnrtting executable applications characterized by; 

a processor (10.11.12) for generating, an executable application, and forming said application into modules 
containing portions of said application and a Directory Module containing information linking modules in an 

so SSh f mrtion element (29.30) for performing one-way hash functions on modules of said application to pro- 

duce corresponding hash values, and cooperating with said processor for inserting sad hash values in said 

Directory Module; . , .... , „ „ .^^^^ 

a source (1 0) of an application provider's public key and a certif icate signed witti a pnvate key of a sy^em con- 
troller and including, an application provider's identifier, and a time stamp related to one of ttie time of genera- 
55 tion and ttie time of expiration Of tiie certificate: , KA^,,ia. 

means (1 1 .12) for attaching said application provider's public key and said certificate to said Directory Module. 

a'^sport processor (14.16) for forming a time division multiplexed signal witti said modules of said applica- 
tion. 
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16. The apparatus set forth in claim 15 further characterized by: 

encryption apparatus for encrypting a hash value of said Directory Module containing hash values of said appli- 
cation modules, with a private key of said application provider; and 

means for attaching encrypted said hash value of said Directory Module to said Directory Module. 

17. The apparatus set forth in claim 15 characterized in that ones of said modules are Data Modules in which data is 
expected to change during execution of said application. arxJ said processor applies version numbers to respective 
modules, and changes the version number of a module when such module changes; 

said hash function element hashes each changed version of a module to produce a new hash value and coop- 
erates with said processor to attach said new hash value to the module to which it corresponds. 

18. The apparatus set forth in claim 1 5 further characterized by: 



a source of a digital version of predetermined text; 

a multiplexer for multiplexing said digital version of predetermined text with said Directory Module, wherein said 
hash function element is conditioned to hash the combination of said digital version of predetermined text and 
the Directory Module. 

19. A method of transmitting executable applications characterized by: 

generating an executable application and segmerrting it into modules; 

forming a Directory Module including information linking respective application modules; 

hashing respective modules with a one way hash function to generate'hash values for respective modules; 

including hash values for respective modules in said Directory Module: 

accessing a certificate including an application provider's identity which certificate is encrypted with a system 
controller's private key; and 

attaching the certificate to said Directory Module, and transmitting said application. 

20. The method set forth in daim 19 further characterized by: 

hashing the directory Module with hash values included therein, to generate a Directory Module hash value; 
encrypting the Directory Module hash value; 

attaching encrypted said Directory Module hash value to said Directory Module; 

21 . The method set forth in daim 1 9 further characterized by: 

genoBting a further certificate including identification of a third party provider; 
encrypting the further certificate with the application provider's private key; and 
attaching encrypted.said further certificate to said Directory Module. 

22. The method set forth in daim 20 further characterized by: 

encrypting said Directory Module with an application provider's private key, and transmitting said encrypted 
Directory Module; and 

transmitting remaining application nrKxJules in plain text 

23. The method set forth in daim 19 characterized in that the st^ of including hash values in said Directory Module 
includes respective hash values of 128 bit length; and 

the step of attaching the certificate to said Directory Module indudes attaching a Certificate induding: 
a 32 bit certificate descriptor or flags, 
a 32 bit ID. 

a 32 bit lifetime expiration descriptor, 
a 32 bit file storage limit, 
a 128 bit name, and 
a 32 bit public key. 
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